\documentclass[10pt,a4paper]{article}
\usepackage[francais]{babel}
\usepackage[utf8]{inputenc}
\usepackage[T1]{fontenc}
\usepackage{pdfpages}
\usepackage{geometry}
\usepackage{fancyhdr}
\usepackage{tabularx}
\usepackage{amsfonts}
\usepackage{graphicx}

\renewcommand{\headrulewidth}{0.4pt}
\renewcommand{\footrulewidth}{0.4pt}
\geometry{ hmargin=3cm, vmargin=3cm }
\pagestyle{fancy}

\newcommand{\cd}[1]{\texttt{#1}}
\newenvironment{Code}[0]
{ \small \ttfamily \begin{minipage}{10cm} }
{ \end{minipage} \normalfont \normalsize }

\title{\Large\bf Interrogations de moteurs de recherche par des requêtes formulées en langage naturel \\ 
  Rapport de projet}
\author{Romain Deveaud \& Ludovic Bonnefoy}

\begin{document}
\parindent=0pt

\maketitle
\newpage
\newpage
\tableofcontents
\newpage

\section{Introduction}
\par La difficulté de la tâche d'interprétation de requêtes en langue naturelle réside dans la transformation d'une phrase grammaticale en une requête pertinente pour interroger un système de RI ou d'extraction d'information. Dans ce rapport, nous présentons un système d'extraction d'information associé à un analyseur de requêtes, dédié à l'analyse et à l'interprétation de questions factuelles formulées en langue naturelle issues de la campagne TREC. Notre système fournit des réponses en exploitant un système composé d'une ressource ontologique et sémantique issue d'un corpus encyclopédique, dont on aura extrait les réponses candidates à l'aide de méthodes statistiques.
\par L'interprétation de requêtes écrites en langage naturel par un système de recherche d'information (RI) ou de dialogue est un enjeu important de l'ingénierie documentaire. Outre le fait que la requête en langage naturel rend possible la formulation d'une requête de recherche selon une forme bien plus précise que la simple saisie de mots clés, elle permet, dans le cadre de la compréhension des languages parlés et des systèmes de dialogue, de déployer des composants de compréhension (SLU) conviviaux pour les utilisateurs. 

\par Dans le cadre des systèmes de Question et Réponses (SQR), l'analyse d'une requête en langage naturel doit permettre de transformer en processus d'extraction d'information, une question factuelle ou complexe. 
%La difficulté de la tâche d'interprétation de requêtes en langue naturelle réside dans la transformation d'une phrase grammaticale en une requête pertinente pour interroger un système de RI ou d'extraction d'information. 

\par Dans ce rapport, nous présentons le système \textit{NLGbAse QR}. Ce système est un extracteur d'information contenues dans une ontologie, associé à un analyseur de requêtes formulées en langue naturelle. 
% Ce système est testé à l'analyse et à l'interprétation de questions factuelles formulées en langue naturelle issues de la campagne TREC. 
%% Deja dans l'intro %%
%Notre système fournit des réponses en exploitant un système composé d'une ressource ontologique et sémantique issue d'un corpus encyclopédique, dont on aura extrait les réponses candidates à l'aide de méthodes statistiques. 

\par La structure de ce rapport est la suivante: 

\par Nous décrivons dans la section ci-dessous les grands principes de la littérature sur l'analyse de requêtes en langue naturelle, et son déploiement dans le cadre de systèmes de Question Réponses (SQR). Puis nous présentons les principaux systèmes de QR existants, et les méthodes de transformation de requêtes sémantiques et d'interrogation qu'ils mettent en oeuvre. 
%Nous expliquons également dans cette section la relation existant entre ontologies issues de corpus encyclopédiques, et le rôle que ces ontologies peuvent jouer dans des SQR. 
\par Dans la section suivante, nous présentons l'architecture du SQR \textit{NLGbAse.QR}. Ce dernier est divisé en trois parties : analyse des requêtes en langue naturelle, transformation des requêtes en paramètres d'extraction, extracteur d'informations appliqué sur une ontologie. Nous détaillons dans la section \ref{details} ces trois modules et les algorithmes qu'ils sous-tendent. 
\par Dans la section \ref{experiences}, nous présentons une évaluation de notre système avec le corpus de question de TREC. Nous concluons par une analyse critique des résultats obtenus, qui sont du niveau de l'état de l'art, et introduisons nos perspectives futures de recherche. 
\par Nous terminons enfin par la mise en perspective du travail réalisé, ainsi que les choix techniques et les difficultés que nous avons rencontrées.

\section{Principe de l'analyse de requêtes en langue naturelle et des SQR}
%%% cette partie est intéressante pour l'état de l'art
\par Des sociétés telles que Google\footnote{http://www.google.com}, Powerset\footnote{http://www.powerset.com} (propriété de Microsoft) ou Hakia\footnote{http://www.hakia.com} sont actuellement fortement investies dans le développement de solutions sémantiques concues en vue  d'une interrogation par des moteurs de recherche et l'enrichissement communautaire en est un élément central, au moins pour les deux premiers protagonistes. L'enrichissement communautaire consiste en l'apport et le partage de nouveau contenu sur un site web par des internautes contributeurs, Wikipédia\footnote{http://www.wikipedia.org} étant le plus célèbre d'entre eux.

\par C'est également notre cas, puisque le système que nous proposons s'interface avec NLGbAse\footnote{http://www.nlgbase.org}, une base de données classifiées (ontologie) provenant de Wikipédia qui peut être interrogée par le biais de trois moteurs de recherche différents. Le premier d'entre eux met en {\oe}uvre un algorithme calculant la \emph{similarité cosinus}~\cite{salton:paper} entre l'ensemble des mots-clés entrés et les documents issus de Wikipédia ; le deuxième est semblable au premier en tous points, à l'exception que l'on peut affiner la recherche en précisant une catégorie, ainsi seuls les documents classifiés comme appartenant à la catégorie spécifiée seront relevés. 
\par La similarité cosinus permet de calculer la similarité entre deux vecteurs à n dimensions en déterminant l'angle entre eux ; pour appliquer cette méthode à la recherche documentaire il convient de transformer le document en un vecteur dans un espace bien choisi. L'espace en question sera un espace dont chaque dimension correspondra à un mot « significatif » du dictionnaire de tous les mots utilisables. Par des méthodes probabilistes décrites dans l'article cité ci-dessus, on va pouvoir calculer un score de similarité entre deux documents qui correspond au cosinus de l'angle entre les deux vecteurs de ces documents représentés dans l'espace. 
\par Le troisième moteur de NLGbAse applique quant à lui un algorithme de compacité~\cite{gillard:paper} permettant de trouver une entité précise appartenant à une catégorie donnée, proche d'un ou plusieurs mots donnés, dans le document Wikipédia se rapportant à une entité nommée donnée, ce qui permet notamment de pouvoir proposer une réponse factuelle à une requête.

\par Ces outils constituent le système de recherche d'information sur lequel nous appliquons les sorties de notre propre système ; ce dernier peut, à partir d'une phrase en langage naturel - de préférence une question, donner les différents mots-clés et catégories attendus par les moteurs de recherche de NLGbAse, et ainsi obtenir une liste de résultats - et éventuellement des réponses factuelles - pertinents.
%Voulez-vous \og{}\emph{vraiment}\fg{} citer~\cite{bogdanoff:these,sonia:point} ?

%%\section{Encyclopédies, ontologies et SQR}

%%% description des ontologies et papiers de référence / WWW / dbpedia / Yago

%% \section{Architecture du système NLGbAse.QR}
%% Que faire dans cette section? A part expliquer pourquoi nous avons utilisé Link-Grammar et Wordnet et comment ils marchent, je ne vois pas.

\section{Algorithmes déployés}\label{details}
\subsection{Analyse morpho-syntaxique et couplage des mots}
\par Pour travailler sur la sémantique, il est indispensable de posséder des outils permettant à la machine de décomposer et d'analyser la structure des phrases. C'est pourquoi nous avons utilisé un analyseur morpho-syntaxique réalisant des couplages de mots selon leur position grammaticale dans la phrase et les liant selon leurs interdépendances~\cite{linkgrammar:paper}. Nous revenons sur cet analyseur et apportons des précisions quant aux caractéristiques qui ont motivé ce choix dans la section 6.3.
% A faire
%Ici une explication du travail effectué par le parser et notre méthode pour trouver les noms propres, l'objet etc... dans une phrase.

%=============================================================
\subsection{Catégorisation des phrases}
%=============================================================
\par Par définition, la sémantique crée naturellement différentes classes de sens plus ou moins générales, au niveau du mot comme de la phrase. Nous adhérons à l'idée selon laquelle la sémantique globale d'une phrase est déterminée par un nombre réduit de mots appartenant à une catégorie grammaticale précise, et c'est selon ce point de vue que nous allons présenter la catégorisation de phrases en catégories sémantiques larges que nous avons implémentée.
%=============================================================
\subsubsection{Catégorisation à base de règles simples}
%=============================================================

\par Notre approche pour catégoriser les questions fonctionne avec un ensemble de règles. Cet ensemble est relativement restreint car nous avons pu remarquer qu'une dizaine de règles environ pouvaient couvrir une majorité des cas, et qu'ensuite chaque petit gain se traduisait par la production d'un grand nombre de nouvelles règles. Les règles que nous avons formulées se basent principalement sur les pronoms interrogatifs présents dans les questions. En voici la liste : 
\begin{itemize}
\item Who, Whom, Whose : \emph{pers} (Person).
\item Where, Whence, Wither : si il s'agit de trouver une catégorie pour le deuxième moteur de NLGbAse, et si un nom propre ou un objet est trouvé, la catégorie sera celle du \emph{nom propre} ou de l'\emph{objet} grammatical de la phrase (par exemple : \og{}Where did Patrick Sébastien study?\fg{}, il y a peu de chance de trouver dans la fiche de ce lieu une mention de cette personnalité et il est à priori plus judicieux de proposer la fiche de \emph{Patrick Sébastien}, dans laquelle l'utilisateur sera à même de touver l'information). Dans le cas contraire (ou si nous voulons une catégorie pour le troisième moteur), la catégorie \emph{loc} (Location) est attribuée.
\item How : nous appliquons la même procédure que précédemment, à l'exception près que si les premières conditions ne sont pas remplies, la catégorie \emph{unk} (Unknown) est attribuée. Pour ce pronom là nous avons ajouté quelques précisions lorsque nous cherchons une catégorie pour le troisème moteur : si le mot suivant directement \emph{how} fait partie de la liste suivante (far, few, great, little, many, much, tall, wide, high, big, old), la catégorie \emph{amount} est attribuée.
\item What, Why, Which : le principe est toujours le même, avec \emph{unk} (Unknown) pour valeur par défaut. Nous avons également établi, comme précédemment, une liste de mots pouvant être acceptés comme suivant directement le pronom interrogatif (comme par exemple day : \og{}What day is the Independance Day?\fg{}) et qui vont impliquer automatiquement l'attribution d'une catégorie (\emph{date} dans l'exemple précédent).
\end{itemize}
Nous allons maintenant détailler les méthodes de catégorisation des noms propres et des noms communs que nous avons mises en place.


%=============================================================
\subsubsection{Catégorisation par les noms propres utilisant NLGbAse}
%=============================================================
\par Comme nous l'avons vu, la majorité des règles ne nous permettent pas de trancher directement, nous devons donc compléter notre analyse par un autre moyen et cela passe notamment par la catégorisation des noms propres. Nous avons remarqué que dans la majorité des cas, si un nom propre est présent dans une question, il en est l'objet ou du moins l'objet est l'une de ses caractéristiques. Prennons par exemple ces deux questions \og{}What is the date of birth of Bruce Dickinson?\fg{}, \og{}Who is Batman's team-mate?\fg{} ; nous voyons bien que les informations désirées sont \emph{forcément} en relation avec ces noms propres.
\par Nous avons donc prit le parti de prendre comme catégorie celle du nom propre se trouvant dans la question - s'il y en a un. Pour cela nous adressons une requête à un script issu de NLGbAse, qui comme nous l'avons vu associe une catégorie à chaque entité de Wikipédia, qui récupère la catégorie de l'entité correspondant à ce nom propre. Si une entité porte exactement le même nom alors la catégorie sera celle de cette entité ; si ce n'est pas le cas mais que des entités ont un nom similaire, alors la catégorie sera celle de la plus pertinente d'entres elles. Enfin si ce n'est pas le cas nous effectuons une recherche par \emph{TF.Idf}
%La solution la plus évidente aurait été de prendre pour catégorie celle du document ayant le meilleur score.
%Nous avons essayé une autre approche. 
en prenant la catégorie qui a le plus fort score, pour cela chaque catégorie se voit attribuée comme score la somme des scores des documents ayant cette catégorie. De ce fait la catégorie qui rassemble le plus de pertinence sera sélectionnée.
\par Cependant nous sommes conscients qu'il arrive parfois que cette stratégie ne soit pas idéale, comme pour : \og{}What is the name of Batman's car?\fg{}. Il y a des chances que cette méthode donne \emph{pers} (Person) comme catégorie attendue alors que la solution idéale aurait probablement été \emph{prod} (Product). Elle n'est néanmoins pas totalement inappropriée car nous devrions trouver l'information désirée dans la fiche Wikipédia de Batman, néanmoins l'accès à la réponse est moins direct.
\par Parfois cette méthode ne donne aucun résultat et il y a plusieurs explications possibles à cela. La première est qu'il est possible qu'il n'y ait pas de fiche relative à ce sujet sur Wikipédia, la seconde est que notre système extrait mal le nom propre et soumet donc quelque chose de faux à NLGbAse. La troisième raison est imputable à l'utilisateur. En effet si l'utilisateur commet une faute dans l'écriture du nom alors NLGbAse ne pourra pas nous donner la bonne réponse. 
\par Pour y remédier nous effectuons une requête avec le nom propre sur Google, ensuite nous regardons si Google suggère une autre orthographe par l'intermédiaire du "Did you mean :". Cependant cette méthode n'est pas infaillible car il est possible que cette même faute d'orthographe soit souvent commise sur Internet et que Google pense que la fausse orthographe soit en réalité correcte.
\par Enfin si à ce stade le nom n'est toujours pas associé à une étiquette alors nous soumettons la phrase au module de CCG de reconnaissance d'entité nommée~\cite{ratinov:paper} basé sur l'architecture SNOW. En effet ce module à de très bonnes performances pour reconnaitre les personnes, organisations et produits.


%=============================================================
\subsubsection{Catégorisation par les noms communs utilisant WordNet}
%=============================================================

\par Toutes les questions ne comportent évidemment pas de noms propres mais généralement des noms communs, c'est pourquoi nous avons du trouver un moyen de traiter ces questions par une approche assez simple. La décomposition morpho-syntaxique nous permet généralement de trouver l'objet de la question, qui possède généralement une forte valeur sémantique ; c'est donc celui-ci que nous allons étudier. En effet, pour la question \og{}What are the generals?\fg{}, l'objet de la question est \og{}generals\fg{} ; l'enjeu est d'arriver à associer \og{}generals\fg{} à l'étiquette \emph{fonc.mil} (fonction militaire).
\par Pour arriver à cela nous utilisons WordNet\footnote{http://wordnet.princeton.edu} et ses hyperonymes ainsi que sa capacité à fournir une classe pour chaque mot : en effet WordNet associe déjà à la totalité des termes une étiquette, par exemple à \og{}general\fg{} il associe \emph{noun.person}. L'étiquette que fournit WordNet est bien souvent satisfaisante, cependant son jeu d'étiquette ne correspond pas aux exigences d'Ester auquel notre projet doit se plier. Ester est une campagne d'évaluation qui vise à mesurer les performances des sysèmes de transcription d'émissions radiophoniques. Elle évalue aussi bien les systèmes complets que leurs composantes, c'est pourquoi elle a créé plusieurs conventions dont une sur les entités nommées\footnote{Disponible à http://www.afcp-parole.org/ester/docs/Conventions\_EN\_ESTER2\_v01.pdf}.
\par La première étape fut d'associer \og{}à la main\fg{} des étiquettes à des mots qui prendront le dessus sur celles de WordNet ; pour reprendre notre exemple, nous ne voulons pas l'étiquette \emph{pers} (Person) pour \og{}general\fg{} mais bien \emph{fonc.mil}. Cependant faire ce travail sur tous les mots demanderait un investissement titanesque, et nous avons pu palier à ce problème en réfléchissant aux mots les plus généraux possibles pour chaque catégorie dont nous avions besoin. Ensuite nous vérifions que les hyponymes de ces mots sur WordNet correspondaient bien à la même catégorie, et si ce n'était pas le cas nous sélectionnions tous les hyponymes pour lesquels c'est le cas et répétions cette opération. Nous sommes donc arrivés à une liste de mots caractérisant parfaitement chaque catégorie - et étant compatibles avec WordNet.
\par L'algorithme de catégorisation en lui-même consiste en une fonction récursive qui va vérifier si le nom commun fait partie des mots étiquetés. Si ce n'est pas le cas cette vérification est faite pour son hyperonyme, et ainsi de suite. La récursivité s'arrête si un mot associé à une étiquette est trouvé ou si on arrive sur l'hyperonyme de plus haut niveau. Dans le premier cas on associe la catégorie trouvée au mot de départ, et dans le deuxième cas c'est l'étiquette associée par WordNet au mot de départ qui prévaut et qui est donc définie comme la catégorie recherchée.
\par Cette méthode utilisée seule ne peut bien évidemment pas couvrir tous les cas, néanmoins c'est l'association des différentes - mais surtout complémentaires - méthodes de catégorisation qui permet d'obtenir des résultats satisfaisants.

%Au final même si il est évident que nous ne couvrons pas tout les cas en seulement trois heures il est possible de couvrir un très grand nombre de cas puisque pour chaque mot étiqueté tout ses hyponymes reçoivent cette même étiquette.

%=============================================================
\subsection{Extraction des mots-clés}
%=============================================================
%Comme énoncé dans la section précédente nous utilisons un parser pour arriver à repérer les termes importants pour la catégorisation et il en est de même pour l'extraction des mots clés.

\par Comme nous l'avons expliqué, les différents moteurs de recherche de NLGbAse n'attendent pas les mêmes entrées, nous allons donc détailler ici les deux types d'extraction de mots-clés - ou mots pertinents.

\subsubsection{Extraction destinées aux moteurs de recherche d'information par similarité cosinus}
\par Dans un premier temps, les mots-outils de la phrase sont automatiquement supprimés à l'aide d'un anti-dictionnaire. Nous utilisons ensuite l'analyse morpho-syntaxique de la phrase, et notamment l'arbre constitutif, pour récupérer les mots - qui ne sont pas des mots-outils - qui constituent groupes nominaux ; malgrès son aspect simple, voire simpliste, nous avons pu prouver empyriquement son efficacité.
\par Cepandant lors de l'évaluation nous nous sommes aperçu que cette aproche n'était pas idéale car elle récupère parfois trop de mots. En effet ceci est génant car les moteurs de NLGbAse fonctionnent en utilisant des '\&' entre les mots-clés. C'est à dire que si un seul des mots clés n'est pas dans le document alors celui-ci n'est pas sélectionné parmis les résultats. Par exemple pour les mots clés \og{}Victor Hugo birth\fg{} aucun document n'est selectionné alors que la requete \og{}Victor Hugo born\fg{} aurait sorti la fiche de Victor Hugo.
\par De plus un autre problème existe et il est lié à Wikipédia. En effet toutes les informations ne sont pas disponibles sur Wikipédia, par exemple il n'existe pas une page pour tous les livres d'un auteur, et une recherche précise pour trouver un livre spécifique ne sortirai probablement aucun résultat.
\par Pour ces deux raisons nous avons fait le choix de sacrifier un très improbable accès direct à l'information en préférant choisir uniquement comme mot clé l'entité nommé, si elle existe, ayant permis de trouver la catégorie. Dans le cas présent nous cherchons a afficher la page de l'auteur plutot que celle du livre (qui a de très grandes chances de ne pas exister si ce n'est pas une oeuvre majeure) dans laquelle l'utilisateur devrait trouver les informations voulues. %et dans le meilleur des cas un lien vers la page du livre en question

\subsubsection{Extraction destinées au moteur de recherche d'information par algorithme de compacité (question-réponse)}
%Pour celui ci la démarche est assez proche mais le besoin de données est différent.
\par Nous l'avons déjà précisé plus haut, ce troisième moteur accepte plusieurs entrées différentes, et notamment deux champs de mots-clés. Le premier champ est une entité nommée qui va déterminer dans quel document sera appliqué l'algorithme de compacité, tandis que le deuxième champ consiste en une liste de mots qui représentent l'information cherchée ; par exemple pour la question \og{}When was Albert Einstein born?\fg{}, le mot \og{}born\fg{} devrait être sélectionné car l'information recherchée - une date de naissance en l'occurence - se trouvera certainement très proche de ce mot.
\par Dans un premier temps nous devons donc trouver l'entité nommée ; si un nom propre est présent dans la question, il sera directement utilisé comme entité nommée. Dans le cas contraire, nous éxécutons une requête sur NLGbAse avec l'objet de la question afin de récupérer le nom de l'entité nommée la plus pertinente. 
\par Dans un second temps vient l'extraction des mots porteurs de sens ; il s'agit tout d'abord de supprimer tous les mots-outils, les noms propres et le verbe présents dans la phrase. Il s'agit ensuite de récupérer les synonymes des mots restant avec WordNet ; pour reprendre notre exemple précédent, nous ne savons pas si le mot \og{}born\fg{} sera effectivement employé dans le document dans lequel l'information sera cherchée, c'est pourquoi nous cherchons des dérivations afin de les rajouter à notre liste et ainsi améliorer nos chances de trouver l'information. Toujours pour notre exemple, cette recherche de synonymes pourrait nous mener au mot \og{}birth\fg{}, qui serait en effet intéressant à garder dans l'optique de la recherche d'une date de naissance.


%==============================================================
\section{Expériences et résultats}\label{experiences}
%==============================================================

%%% modif eric
\par La vocation de notre algorithme est de transformer une question en langue naturelle en une requête compatible avec un système de RI.  Pour mesurer les performances de notre système, nous évaluons sa capacité à étiqueter une question en vue de l'extraction des informations requises pour construire une requête ainsi que la pertinence des mots-clés extraits.
%Dans un second temps nous construisons une requête d'après les informations extraites et mesurons la pertinence des résultats retournés par l'un des trois moteurs de NLGbAse.

\subsection{Corpus de référence et standard de mesure}
\par Nous avons séparé les deux tâches que sont la RI et l'analyse sémantique de la phrase, c'est pourquoi l'évaluation de notre système porte sur la catégorisation et l'extraction de mots-clés. Nous avons utilisé pour ces mesures des corpus de questions déjà existants qui ont été mis au points dans le cadre de campagnes d'évaluation telles que Trec 12. %%i% citer %%% 
\par Le corpus \textit{Question Answering Collections} de Trec est composé de 500 questions factuelles\footnote{En téléchargement sur http://trec.nist.gov/data/qa/2003\_qadata/03QA.tasks/test.set.t12.txt.html}, organisées dans un fichier XML comme suit : 

\begin{verbatim}
<top>
<num> Number: 1919
<type> Type: factoid
<desc> Description:
How big is Mars?
</top>
[...]
\end{verbatim}

\par Notre choix s'est porté sur cette année là car ultérieurement le format des fichiers a changé et est devenu à notre sens beaucoup trop spécifique à la tâche de question réponse. En effet les corpus les plus récents proposent des séries de cinq questions en rapport avec une cible donnée. On voit bien là que l'approche est toute autre. En effet pour le moteur de RI classique avec lequel nous travaillons, la meilleure manière d'obtenir un document comportant la réponse est de choisir la fiche correspondant à la cible. L'évaluation de notre application sur ces corpus n'aurait donc eu que très peu de sens. De plus nous trouvions qu'une évaluation de ce type est vraiment superficielle et ne reflète pas les résultats que le système fournirait à un utilisateur qui ne préciserait pas la cible de la question. 
\par Ce corpus n'étant pas initiallement prévu pour vérifier l'expérience d'étiquetage de questions tel que prévu dans le cadre de notre algorithme, nous avons procédé à son enrichissement \og{}à la main\fg{}.
\par Cet enrichissement consiste a attribuer à chaque question la catégorie sémantique de la réponse attendue (nous n'avons retenu que les classes racines à savoir \emph{pers}, \emph{org}, \emph{loc}, \emph{date}, \emph{amount} et \emph{unk}), ainsi que les différents mots-clés qui peuvent permettre d'obtenir une réponse. Nous disposons ainsi d'un corpus de questions et de réponses de références complétées par des informations sémantiques compatibles avec notre système\footnote{Ce corpus complété est disponible sur www.nlgbase.org}. 
\par Pour des raisons pratiques, nous avons créé notre propre formalisme :
\begin{verbatim}
<question en toutes lettres>#
<mots-clés attendus par les moteurs de RI>#<catégorie de l'entité source>#
<nom de l'entité source>#<mots-clés probablement proches de la réponse>#
<catégorie de l'entité réponse cherchée> 
\end{verbatim}

\par Ainsi, dans l'exemple précité, nous complétons la description de la question par plusieurs étiquettes de classes, à savoir que l'entité source est une localisation, et que la réponse cible est une quantité (\emph{amount}, la taille de la planète Mars) :

\begin{verbatim}
How big is Mars?#Mars#loc#Mars#big#amount#
[...]
\end{verbatim}

%% plus d'actualité
%%\par Le corpus est également composé de 108 questions prélevées aléatoirement sur le site AnswerBus\footnote{http://www.answerbus.com/}, qui est également un système de rechercher d'information par question-réponse. La particularité de ces questions est qu'elles ont été formulées par des utilisateurs, une majorité d'entre-elles n'est donc pas grammaticalement parfaite ; nous avons trouvé ce corpus intéressant pour tester notre système car cela nous permet de nous rapprocher de la réalité par rapport aux questions classiques de campagnes d'évaluation.

\par Nous avons ainsi lancé notre système pour chacune des questions de ce corpus et mesuré les différences entre l'étiquetage \og{}à la main\fg{} et les sorties du système. Nous avons pu en déduire des mesures de précision et de rappel complétées par le F-Score\footnote{Mesure harmonique combinant la précision et le rappel} que nous vous présentons dans la sous-section \ref{evaluation}.

%%validité de son étiquetage sémantique et de l'identification des mots clés pertinents pour une extraction de réponse, puis la pertinence des réponses retournées par le moteur de recherche par rapport à la réponse de référence. Ces mesures sont réalisées par un calcul de score de 

%% retrait eric
%Les sorties réelles de notre système ont donc été comparées avec notre corpus, et nous avons ainsi pu calculer les diverses mesures présentées ci-dessous.

%\par Nous avons procédé à un certain nombre de tests et d'expériences afin d'évaluer les performances de la catégorisation comme de l'extraction des mots-clés. Nous n'avons retenu que les classes racines à savoir \emph{pers}, \emph{org}, \emph{loc}, \emph{date}, \emph{amount} et \emph{unk}. 

%\par Nous nous sommes appuyés sur un corpus de 
%% il faudra mettre le nombre de questions (107 pour le moment)
%questions issues de TREC 8 que nous avons étiquettées \og{}à la main\fg{} comme si c'était des sorties de notre système. Pour chaque question, nous avons déterminé la catégorie sémantique de l'information attendue et les différents mots-clés nécessaires pour une recherche correcte de cette information - comme nous l'avons déjà expliqué dans ce rapport. Les sorties réelles de notre système ont donc été comparées avec notre corpus, et nous avons ainsi pu calculer les diverses mesures présentées ci-dessous.

%% pas bon ça il faut être affirmatif et plus précis %%%
%les standards d'Ester 2 n'étant pas encore complètement implémentés sur la version anglaise de NLGbAse. Nous avons récupéré un corpus de questions formulées par des utilisateurs et nous les avons étiquetées en faisant mentalement le même travail que notre système, afin de pouvoir comparer ses résultats aux notres. 

\subsection{Mesures de la catégorisation sémantique}\label{evaluation}

\par Les résultats de l'attributions de catégories aux 492 phrases de notre corpus étiqueté sont présentés dans le tableau 1. 
%Nous avons calculé pour chacune d'elles la précision et le rappel, puis le F-Score\footnote{Mesure harmonique combinant la précision et le rappel} en découlant.
\par Ces résultats mettent en perspective le fait que des règles simples couplées à une catégorisation par recherche dans une base de données sémantique peuvent être viables. Les résultats de la catégorie \emph{org} peuvent être expliqués par le fait qu'il n'existe pas de règle spécifique à cette catégorie, tous les essais que nous avons fait pour y remédier impactaient fortement les résultats des autres catégories, notamment \emph{pers} et \emph{loc}.

    \begin{center}
        \begin{tabular}{|p{2.5cm}|l|l|l|}
            \hline
            Catégorie & (\={p}) & (\={r}) & (\={F}-s) \\
            \hline
            Pers & 0.81 & 0.81 & \textbf{0.81} \\
            \hline
            Org & 0.64 & 0.61 & \textbf{0.63} \\
            \hline
            Loc & 0.76 & 0.77 & \textbf{0.76} \\
            \hline
            Date & 0.91 & 0.98 & \textbf{0.95} \\
            \hline
            Amount & 0.99 & 0.92 & \textbf{0.92} \\
            \hline
            Unk & 0.69 & 0.64 & \textbf{0.66} \\
            \hline
            \hline
            Total & 0.80 & 0.78 & \textbf{0.79} \\
            \hline
        \end{tabular}
        \caption{\label{tab:results}Précision (\={p}), Rappel (\={r}), F-Score (\={F}-s) obtenus sur le corpus QA de TREC 12}
    \end{center}
\end{table}

\subsection{Mesures de l'extraction de mots-clés}

\par Nous avons également mesuré la pertinence des mots-clés extraits par notre système. Comme précédemment nous avons tout d'abord effectué \og{}à la main\fg{} le travail d'extraction, puis nous avons comparé ceci avec les résultats du système afin d'obtenir un score de satisfaction calculé selon la formule suivante : $$S(C) = \frac{\sum_{i = 1}^{N} P(Q_i)}{N}$$
\par Ils sont présentés dans les tableaux ci-dessous.

\begin{table}[htbp]
    \begin{center}
        \begin{tabular}{|p{12cm}|l|}
            \hline
            Type de mots-clés & (S(C)) \\
            \hline
            Mots-clés extraits pour une recherche par similarité cosinus & \textbf{54.03\%} \\
            \hline
            Entités nommées extraites pour une recherche de type question-réponse (compacité) & \textbf{66.23\%} \\
            \hline
            Mots-clés extraits pour une recherche de type question-réponse (compacité) & \textbf{73.28\%} \\
            \hline
        \end{tabular}
        \caption{\label{tab:results}Satisfaction (S(C)) obtenue sur le corpus de test}
    \end{center}
\end{table}

\par Ces derniers chiffres peuvent être expliqués par le fait qu'il est assez difficile de se mettre à la place d'un système de RI et d'imaginer quels paramètres seront les plus pertinents pour obtenir un bon résultat, les mots-clés que nous avons extrait \og{}à la main\fg{} pour établir notre corpus de test sont donc parfois éloignés de la formulation optimale.

\subsection{Commentaires et comparaisons}
\par Ces résultats nous ont permis de comparer notre système avec certains des meilleurs systèmes actuels
%. Force est de constater que nous sommes nettement en dessous de leurs résultats 
 comme par exemple le système de CCG~\cite{learning:paper} qui obtient un score de 90\% à 95\% de bonne classification. Néanmoins celui-ci est basé sur l'architecture d'apprentissage automatique SNOW, contrairement à notre approche basée sur des règles simples et l'utilisation d'hyperonymes.
%Cependant les méthodes utilisées par ces systèmes sont basé sur des méthodes d'apprentissage automatique. Avant même le début de notre application nous étions conscient que de tels systèmes permettaient d'obtenir des résultats meilleurs que ceux obtenu avec des méthodes et des règles faites manuellement. Cependant notre propos est plutôt de démontrer qu'il est possible d'obtenir des résultats interessants en utilisant un faible nombre de règles et de ressources ainsi que des algorithmes simples.
De plus notre méthode est facilement adaptable à d'autres langues 
%à condition que Wordnet la supporte (ou a moins de trouver des ressources identiques dans la langue voulue), d'avoir un parser dans cette langue et de traduire les quelques règles dans la langue cible. 
 et nous obtiendrions alors des résultats à peine plus faible que le système multilingue de Thamar Solorio et al.~\cite{solorio:paper} utilisant des heuristiques complexes et ayant recours aux SVM.
%\par Enfin les résultats sont impactés par le fait que cette application dépends de plusieurs outils tel que NLGbAse qui est encore en développement et qui commet encore des erreurs que nous répétons, et tel que l'analyseur syntaxique linkgrammar qui bien qu'ayant l'avantage d'être libre n'est pas le plus performant existant et qui commet aussi des erreurs (par exemple sur l'objet de la question qu'il associe frequemment au pronom interrogatif).

\section{Majecstic 2009}
\par Majecstic\footnote{http://majecstic2009.univ-avignon.fr/} est une conférence qui a entre autres buts de permettre à des jeunes chercheurs de publier sur leurs recherches actuelles. Cette année cette conférence se tient à Avignon et notre tuteur nous a proposé d'y participer en y soumettant un article sur notre projet. Y voyant là une expérience intéressante et enrichissante nous avons donc écrit un article décrivant le but de notre projet, notre approche et nos résultats. Cet article reprends de nombreux éléments présents dans ce rapport. %Malheuresement à l'heure actuelle nous ne pouvons pas savoir si il sera retenu.

\section{Choix techniques}
\subsection{Un langage de script : Ruby}
\par Lorsqu'il a créé Ruby, Yukihiro Matsumoto a dit qu'il "voulait un langage de script plus puissant que Perl, et plus orienté objet que Python". Dans Ruby, le paradigme de base est que tout y est un objet. Chaque entité d’information et code peut recevoir ses propres propriétés et actions. La programmation orientée objet fait référence aux propriétés sous le terme de variables d’instance et aux actions sous le nom de méthodes.
\par Ruby a pour réputation d’être un langage pour le moins flexible, puisqu’il autorise son utilisateur à en modifier les entrailles. Des parties importantes peuvent être retirées ou redéfinies à loisir ; des greffes de fonctionnalités sont possibles en cours de route. En définitive, Ruby essaye de ne pas contraindre le programmeur.
\par C'est cette grande flexibilité que nous avons appréciée dans ce langage, ainsi que sa capacité à rendre la programmation aussi naturelle que possible. Notre tuteur nous ayant précisé au début de l'année que nous n'avions pas de contraintes spéciales au niveau du langage de programmation, nous avons décidé de nous lancer sur ce langage qui proposait les outils dont nous avions besoin (voir les paragraphes ci-dessous), et qui nous permettrait de nous imprégner de nouvelles méthodes de programmation liées aux langages que nous connaissons déjà ; dans notre cas, Ruby revendique des liens très forts avec Perl, Smalltalk, Eiffel, Ada et Lisp.% En effet nous pensons qu'il n'est pas important de maîtriser \textit{tous} les langages de programmation, mais qu'en essayer de comprendre l'essence et la philosophie d'un nombre réduit d'entre eux nous pourrons très facilement et rapidement apprendre de nouveaux langages par la suite. Dans notre cas, Ruby revendique des liens très forts avec Perl, Smalltalk, Eiffel, Ada et Lisp.
\subsection{WordNet}
\par "WordNet est une base de données lexicale développée par des linguistes du laboratoire des sciences cognitives de l'université de Princeton. Son but est de répertorier, classifier et mettre en relation de diverses manières le contenu sémantique et lexical de la langue anglaise."~\cite{wikipedia:wordnet}
\par Nous avons choisi d'utiliser cet outil car il est d'une très grande richesse et contient un dictionnaire très volumineux. Ce qui nous a interessé en premier lieu chez Wordnet est le système d'hyperonymes et d'hyponymes. Un terme A est un hyponyme de B si il en est un constituant, une partie, ou encore une précision. B est alors l'hypéronyme de A. Par exemple "roue" est un hyponyme de "voiture". En effet comme nous avons pu le voir dans la partie dédiée au fonctionnement de NLGbAse.QR cela nous permet de trouver le type attendu par l'utilisateur en associant des catégories à un ensemble de mots de haut niveau et ensuite en prenant l'objet d'une question et en remontant l'arbre des hypéronymes jusqu'à obtenir l'un des termes étiquetés.
\par De plus nous utilisons aussi sa capacité à fournir des synonymes afin d'élargir la listes des termes près desquels il est possible de trouver l'entité voulue pour le moteur utilisant la compacité.
\par Wordnet offre donc les avantages d'un dictionnaire de synonymes auquel on rajoute les liens d'hyperonymie ce qui permet de n'utiliser qu'un seul outil. Enfin Wordnet dispose d'une API dans de nombreux langages dont Ruby ce qui le rend totalement adapté pour notre application.

\subsection{Une analyseur syntaxique : LinkParser}
\par Lors de nos recherches nous avions remarqué quatres analyseurs syntaxiques de qualité : XIP\footnote{Démonstration disponible à www.xrce.xerox.com/xip/page1.jsp}, LinkGrammar\footnote{http://www.link.cs.cmu.edu/link/}, TreeTagger\footnote{Disponible à http://www.ims.uni-stuttgart.de/projekte/corplex/TreeTagger/} et LiaTagg\footnote{http://lia.univ-avignon.fr/fileadmin/documents/Users/Intranet/chercheurs/bechet/download\_fred.html}.
\par Le premier est probablement le plus complet et le plus performant cependant il faut disposer d'une license d'utilisation ; nous avons longuement hésité à demander une license étudiante car il fonctionne dans de nombreuses langues, détecte les entités nommées, l'objet de la question\ldots Cependant nous ne voulions vraiment pas que ce projet puisse être compromis si l'accord de license était rompu ou si il ne nous était plus attribué gracieusement.
\par TreeTagger quant à lui a pour principal défaut de mettre un temps considérable à démarrer (environ 2 à 3 secondes), ce qui l'a directement éliminé. LiaTagg semble obtenir des résultats comparables à TreeTagger et propose son résultat instantanément, tout comme LinkGrammar qui répond lui aussi de manière rapide et satisfaisante.
\par Notre choix s'est porté sur LinkGrammar plutôt que sur LiaTagg pour trois raisons. La première est que LinkGrammar dispose d'une API Ruby nommée LinkParser, ce qui facilite son intégration au projet. La seconde est qu'il est beaucoup plus facile de trouver des informations sur celui-ci ainsi que le programme en lui-même (car il semblerait que le seul moyen actuellement de trouver LiaTagg est d'aller sur la page personnelle de Frederic Bechet). La troisième est qu'elle permet d'obtenir, à l'instar de XIP, l'objet de la question. Cependant la comparaison avec XIP s'arrête là, car hélas il s'avère que le nombre d'erreur est très important (probablement du au fait que nous lui soumettons exclusivement des questions, avec des formulations probablement peu correctes). Enfin la documentation de LinkParser\footnote{http://www.link.cs.cmu.edu/link/api/index.html} est très bien détaillée et est agrémentée d'exemples, et Michael Granger, son développeur, est très accessible et n'a pas hésité à réfléchir avec nous sur un bug de LinkParser et de nous donner la solution.

\subsection{GoogleCode : un outil combinant la gestion de projet et le versionning de sources (via SubVersion)}
\par GoogleCode permet, à l'instar de SourceForge, de gérer les versions d'un projet. Il propose plusieurs fonctionnalités, telle que des \textit{issues} (ou problèmes) qui permettent de signaler les problèmes à régler, les choses à faire ou les modules à implémenter et de les attribuer à une personne ainsi que d'y associer une priorité. Il permet aussi de pouvoir naviguer dans le code source parmis les différentes versions ainsi que de comparer directement les modifications d'un document entre différentes versions.
\par Nous avons fait le choix d'utiliser GoogleCode plutôt que SourceForge, Trac ou encore Redmine car il n'est pas nécessaire d'installer quoi que ce soit pour l'utiliser (il suffit de disposer d'un compte google), de plus la création d'un projet se fait en quelques secondes. De plus notre choix s'était porté sur SubVersion (qui est supporté par GoogleCode, au même titre que Mercurial) car il est l'un des gestionnaires de versions les plus populaires, et nous esperions que nous pourrions à terme le faire faire installer au CERI. C'est d'ailleurs une critique que nous pouvons formuler à l'encontre de l'organisation des projets, nous devons fournir tous les sources au CERI, mais rien n'est mis en place pour les stocker, les gérer et les rendre accessibles au plus grand nombre.
%\par De plus GoogleCode disposant d'un moteur de recherche dédié, il est possible d'associer au projet des mots-clés afin que d'autres utilisateurs puisse le retrouver facilement.


\section{Bilan global}
\subsection{Recul sur le travail effectué}
\par Comme nous l'avons vu dans la section précédente, nous aurions pu utiliser différents outils pour ce projet. Tout d'abord nous aurions pu utiliser un autre langage interprété comme Perl, langage disposant aussi d'une API Wordnet et d'un analyseur syntaxique. Wordnet cependant n'aurait pas put être remplacé entièrement, même si il aurait était possible d'utiliser d'autres dictionnaires de synonymes, la partie sur les hyperonymes aurait été plus difficile à trouver ailleurs. De plus le fait que l'on puisse trouver toutes ces choses en un seul outil est vraiment intéressant. Si nous recommencions notre projet, il y a fort à parier que nous utiliserions à nouveau les données que peut apporter Wordnet. Quant à l'analyseur syntaxique, nous en changerions certainement. Comme nous l'avons exprimé plus haut, LinkParser arrive difficilement à bien étiqueter les questions et à en trouver l'objet. Malheuresement, après quelques test, nous nous sommes aperçus que tout les autres analyseurs syntaxiques cités éprouvaient à peu près les mêmes difficultés. Cependant il est fort probable que nous opterions pour XIP car il est le plus performant des parsers essayés et il supporte de nombreuses langues (LinkParser ne fonctionne que pour l'anglais, LiagTagg et TreeTagger fonctionne aussi pour le français).
\par Pour le vesionning, GoogleCode était plus que satisfaisant pour l'ampleur de notre projet. Enfin pour ce qui est du blog que nous avons tenu\footnote{http://semanticqa.wordpress.com} (au début de ce projet surtout) sur l'avancement de nos recherches, Wordpress propose gratuitement un outil très performant. Malheuresement là aussi il a était impossible de le faire installer sur les serveurs du CERI.
\par L'un des problèmes que nous avons rencontré ce semestre est le fait que NLGbAse est encore en projet et donc en perpetuelle modification. Par exemple pour catégoriser les noms propres nous utilisons un script Perl (qui est une version modifiée du script de NLGbAse) afin d'obtenir les sorties et les résultats souhaités pour notre application. Nous avons du modifier largement ce script à plusieurs reprises afin de suivre les évolutions de NLGbAse, et il y a fort à parier que d'ici quelques temps ce script sera à modifier de nouveau. 
\par Ensuite, comme nous l'expliquions dans la section 4, nous avons évalué notre système uniquement sur les quelques catégories de plus haut niveau. Ceci n'était pas dans le but d'améliorer nos résultat, mais il nous était impossible d'évaluer l'ensemble des sous-catégories car elles ne sont pas toutes encore en vigueur sur NLGbAse. Nous aurions donc testé notre application sur des catégories qu'il n'aurait jamais pu trouver, ce qui aurait induit un score d'erreur très important. De plus il existe encore de nombreuses erreurs de classification dans NLGbAse qui sont corrigées au fur et à mesure de son évolution et de notre utilisation. Cependant notre système a d'ores et déjà la possibilité de prédire des classes plus précises à l'heure actuelle. Lorsque NLGbAse comportera l'ensemble de ces catégories, notre système fonctionnera avec celles-ci sans modifications au code, en cela nous avons donc de "l'avance" et avons anticipé cette évolution future de NLGbAse.
\par Il serait intéressant de reprendre ce projet d'ici un an ou deux lorsque NLGbAse aura atteint une certaine stabilité et une plus grande efficacité afin de connaitre les résultats de notre application sur un plus grand nombres de catégories et de voir si des modifications ou des ajustements sont à prévoir. Bien que nos résultats soient corrects, ils restent relativement faibles par rapport à certains autres systèmes sur un si petit nombre de catégories. Il aurait été vraiment intéressant de pouvoir se comparer à d'autres systèmes prédisant un nombre de classes plus important car nous pensons ne pas perdre beaucoup au niveau de nos scores en utilisant l'ensemble des catégories d'Ester. Cela nous aurait permis de prouver que notre approche était valable avec un nombre important de catégories et assez proche du niveau de l'état de l'art.
\subsection{Autres orientations envisageables}
\par Comme nous l'avions annoncé lors du semestre dernier, nous avions envisagé d'opter pour une approche basé sur des techniques d'apprentissage automatique. Nous esperions pouvoir suivre le cours d'apprentissage automatique afin d'en comprendre le fonctionnement ainsi que les différentes méthodes. Hélas avec les mouvements de grèves le début de ces cours a été reporté à près de deux mois après le début du semestre et nous avions déjà beaucoup avancé dans la voie que nous avons présenté dans ce rapport. 
\par Néanmoins nous nous sommes rendu compte avec ces cours qu'il nous aurait fallu un très grand nombre de questions en langage naturel afin de pouvoir réaliser un apprentissage correct. En étiquettant les corpus que nous avons à disposition (plus de 15000 questions en anglais issues de campagnes d'évaluations ou d'utilisateurs) il serait possible de mettre en oeuvre certaines de ces solutions, cependant cela nécessiterait une longue et plus que fastidieuse phase d'étiquetage nécessaire pour l'apprentissage.
\par Dans l'approche mise en place nous avons décidé de ne produire qu'une seule catégorie pour une question et ce pour être en accord avec le moteur actuel qui n'en prend qu'une en paramètre. Nous aurions pu ici choisir une méthode probabiliste et prédire ainsi plusieurs catégories pour une même phrase, associées chacunes à une probabilité de vraisemblance. Ainsi nous aurions modulé les scores des documents de chaque catégorie en fonction de cette probabilité. Cependant cette méthode, comme celles basées sur l'apprentissage, demande l'étude de nombreux cas pour trouver les probabilités qui collent le plus à la réalité afin de créer un modèle viable.
\par Ensuite il y a des informations que nous aurions pu obtenir aisément à l'aide d'analyseur morpho-syntaxique que nous n'avons pas utilisé. Par exemple des informations telles que le sujet de la phrase, les compléments d'objet directs, les liens entre les mots, etc\ldots Cependant notre but était d'arriver à faire un système qui fonctionne bien avec peu de règles et d'en éviter la prolifération ce qui aurait été le cas si nous avions tenu compte de ces informations. Par contre il y a fort à parier qu'utiliser ces informations dans une méthode d'apprentissage serait intéressant.
\par Il serait aussi intéressant d'adapter ce travail pour plusieurs langues. Il n'y aurait en réalité qu'une dizaine de règles simples à transposer dans ces langues et utiliser un nouvel analyseur syntaxique supportant ces langues ainsi qu'une version améliorée de WordNet (comme elle existe par exemple pour le français). NLGbAse supportant déjà quatre langues qui sont l'anglais, le français, l'allemand et l'espagnol, le travail qui serait à fournir serait plus un travail de traduction de règles et de mots pour Wordnet et ne poserait aucune difficulté algorithmique. 
\par On pourrait alors envisager deux cas : le premier où l'on dispose d'un parser dans cette langue et qui nous permettra d'extraire le nom propre avec peu d'erreurs, ainsi que l'objet de la question. La seconde ou il faudrait traduire la phrase et l'analyser avec un parser en anglais. Cette deuxième option, bien que l'on puisse penser qu'elle commettra de nombreuses erreurs, fonctionnerait probablement mieux que l'on ne le croit. En effet dans la majorité des cas nous nous servons surtout des noms propres et même si la question n'est pas parfaitement traduite il y a de fortes chances pour que l'analyseur syntaxique le trouve (grâce à la première lettre en majuscules par exemple). 
%Et dans le cas où il n'y a pas de noms propres et où alors nous étudierons les mots communs, il n'est pas très important qu'ils soient organisés dans le bon ordre dans la phrase à chaque fois puisque c'est mot à mot que nous les utilisons dans le module avec Wordnet. (par exemple pour la question : Qui est la femme de Nicolas Sarkozy? traduite en anglais par Google cela donne "Who is the wife of Nicolas Sarkozy?". Une traduction plus heureuse aurait été "Who is Nicolas Sarkozy's wife?". Cependant nous obtenons dans les deux cas les mêmes catégories et les mêmes mots clés extraits et donc exactement les mêmes résultats"). De plus il serait aisé d'utiliser un système de sélection de la langue automatique (avec possibilité de mofication par l'utilisateur en cas d'erreur) en fonction des mots interrogatifs utilisés).
\subsection{Apports du projet et valeur ajoutée}
\par Ce projet nous a beaucoup apporté sur plusieurs plans très différents. Tout d'abord nous avons du apprendre à nous documenter, à chercher par nous-même, à lire des articles scientifiques pas toujours très accessible, ainsi qu'à les comprendre, les interpréter, tirer nos conclusions et les mettre en perspective par rapport à notre projet. Il faut savoir également que ce travail a parfois été frustrant car nous n'avions pas la méthodologie nécessaire pour trouver les informations que nous cherchions par nous-même parmis tous les articles relatifs au traitement de la langue naturelle, mais il a été très gratifiant de trouver quelques idées originales en s'appuyant sur ces publications.
\par Nous avons ensuite eu l'occasion de toucher à plusieurs facettes du monde de la recherche, notamment la rédaction et la soumission d'un article, ce qui nous sera certainement très utile pour la suite de notre cursus. 
\par Enfin, nous avons pu appliquer nos connaissances en génie logiciel et en programmation pour concevoir un logiciel fini et utilisable par d'autres utilisateurs ou chercheurs, notamment grâce à une procédure d'installation complète. Nous avons également pu découvrir un nouveau langage à la popularité montante.
\par Pour résumer, ce projet nous a permis aussi bien de développer une culture générale solide du Traitement Automatique du Langage Naturel, de découvrir le monde de la recherche et d'améliorer nos connaissances techniques en programmation.

%==============================================================
\section{Conclusion}
%==============================================================
\par Nous avons présenté un système analysant et décomposant des requêtes formulées en langage naturel dans le but d'en extraire leur catégorie sémantique ainsi que les mots porteurs de sens et d'information, destiné à être couplé avec un système de recherche d'information que nous avons présenté. Les résultats obtenus sont encourageants et démontrent qu'un petit nombre de règles couplées à un outil d'analyse morpho-syntaxique et de reconnaissance des entités nommées peuvent constituer une approche viable dans la tâche de RI en langage naturel.% Néanmoins ces résultats sont à relativiser car nous n'avons travaillé que sur la langue anglaise qui, de part sa structure grammaticale, nous a permit de gérer un grand nombre de cas par un petit nombre de règles, ce qui ne serait pas le cas en français par exemple.
\par Le système NLGbAse.QR\footnote{http://sit.vickev.fr/semantic-ruby/www/} peut être expérimenté en ligne et le corpus de test que nous avons utilisé est mis à disposition sur le site de NLGbAse.
\par Ce projet a été très instructif sur plusieurs points : en effet nous avons pu découvrir le monde de la recherche de part la nature du projet et grâce à l'article que nous avons écrit. Nous avons du développer de nouvelles compétences nécessaires pour la recherche d'articles et de documentation relative à notre domaine de recherche, et nous avons du améliorer notre discipline et faire preuve de rigueur dans la rédaction de nos rapports. Nous avons également amélioré nos compétences techniques en apprenant un nouveau langage de programmation et de nouveaux outils que nous avons du découvrir et maîtriser (parfois même débugger).
\par Nous pouvons donc dire que ce projet aura été très enrichissant car nous avons acquis de nombreuses nouvelles compétences qui nous serviront assurément quelle que soit la suite de notre cursus universitaire ou professionnel.
%% conclusion a completer


\bibliographystyle{majecstic}
\bibliography{references}

\end{document}
